项目 内容
这个作业属于哪个课程 课程社区
这个作业的要求在哪里 作业要求
我在这个课程的目标是 凝聚整个团队通过一定的软件开发流程，在预计时间内发布”足够好”的符合用户需求的软件，并证明其是可维护和持续发展的，并在其中做出应有的贡献，提升进行软件工程开发的能力。
这个作业在哪个具体方面帮助我实现目标 通过整理测试报告，发现测试的覆盖程度是否足够，为后续是否提高覆盖率等提供了决策依据。

[T.11] 团队项目：Alpha 阶段测试报告

1. 测试目标与范围

WildCard 的 Alpha 阶段目标是跑通“自定义规则 -> 创建房间 -> 玩家加入 -> 准备开局 -> 对局执行 -> 结算返回”的最小闭环。根据现有功能规格和技术规格，本次测试重点放在以下几条主线上。

  • 用户系统：注册、登录、退出、当前用户状态、用户名修改、密码修改、token 携带、登录失败状态保持。
  • 房间系统：创建房间、加入房间、密码房间、准备状态、离开房间、房主开始游戏、房间路由守卫。
  • 对局系统：战斗页展示、出牌合法性、跳过动作、结算展示、非当前玩家动作拒绝。
  • 规则系统：规则构建页面、JSON 预览、规则结构面板、保存草稿、编辑草稿、完成并上传规则、规则引擎解析、规则引擎动作执行。
  • WebSocket 房间状态：用户加入、离开、重复加入、多用户参与者列表、事件复制。
  • 工程质量：前端单元测试、前端 E2E、前端构建、后端格式检查、Clippy、后端测试。

2. 测试过程

  • CI/CD 对前端执行依赖安装、单元测试和生产构建检查。
  • 前端单元测试覆盖 API 请求层、用户状态、房间页面、准备房间、对局页面、规则构建器组件和基础工具函数。
  • 前端构建检查验证 TypeScript 类型、Vue 编译和 Vite 打包流程可以通过。
  • CI/CD 对后端执行格式检查、Clippy 静态检查和 Rust 测试。
  • 后端测试覆盖用户注册登录、退出、查找用户、房间创建、规则 payload 校验、规则引擎执行和 WebSocket room session mock。
  • Pull request 和主分支推送都会触发基础回归检查，用于确认合并前前后端主流程没有明显退化。
  • 当前流水线重点验证单元测试、组件测试、构建和后端逻辑测试；测试数据库、真实 HTTP E2E 和覆盖率统计作为后续补充项。
编号 问题 原因 状态
BUG-001 前端无法访问后端接口 API base URL 和后端实际路由前缀不一致，部分请求打到了错误路径 已修复
BUG-002 未登录用户可以进入创建房间流程 前端路由守卫没有覆盖创建房间、加入房间和规则构建等受保护页面 已修复
BUG-003 顶部 info 的三个跳转入口点击后会短暂跳转，又迅速回到个人信息页面 用户页 tab 状态和路由 query 同步时机不一致，组件重新挂载后使用默认个人信息 tab 覆盖了目标 tab 已修复
BUG-004 用户头像无法加载，Gravatar 链接显示失败 头像地址依赖外部 Gravatar 服务，部分网络环境下被阻断；前端缺少本地头像 已修复
BUG-005 创建房间后偶发停留在创建页，没有自动进入准备房间 创建房间接口返回字段使用 room_code，前端跳转逻辑读取的是 code，字段归一化不完整 已修复
BUG-006 用户已经进入房间后，首页无法返回已进入房间 前端“返回房间”按钮显示条件依赖当前房间缓存，但页面初始化时没有及时读取缓存状态，导致按钮未正常显示 已修复
BUG-007 加入房间时输入小写房间号会提示房间不存在 前端没有在提交前统一 trim 和转大写，后端按大写房间号查询 已修复
BUG-008 两个人在同一房间时，一个人离开后，另一个客户端仍显示该用户在房间内 房间参与者状态只在本地更新，离开事件没有稳定广播到其他客户端；mock session 也缺少离开未知用户和重复加入边界覆盖 已部分修复，真实 WebSocket 广播待补
BUG-009 游戏结束后返回准备房间，页面仍显示上一局的手牌和结算信息 对局状态缓存在前端 store 中，房间状态恢复 waiting 时没有清理上一局 battle state 已修复
BUG-010 rule_engine 调用规则 API 时出现解析错误 前端导出的规则 JSON 中部分流程节点缺少后端需要的开始节点或跳转目标，后端错误信息不够清晰 已修复并补充解析边界测试
BUG-011 完成并上传规则后，创建房间页的规则列表没有立即出现新规则 草稿上传为可用规则后只更新了规则构建器页面状态，没有刷新创建房间页使用的规则列表缓存 已修复

3. 场景测试

3.1 场景一：普通玩家加入朋友房间并参与对局

用户画像：

  • 有账号。
  • 不创建规则，只想输入房间号加入朋友创建的房间。
  • 目标是快速进入房间、准备、开始游戏、按提示出牌。

预期流程：

  1. 用户登录。
  2. 点击加入房间。
  3. 输入房间号，必要时输入密码。
  4. 进入准备房间。
  5. 点击准备。
  6. 房主开始游戏后进入对局页。
  7. 轮到自己时选择手牌并出牌。
  8. 对局结束后查看胜负结果。

当前测试覆盖：

  • 用户登录状态由 store 测试覆盖。
  • 加入房间页面覆盖空房间号、有密码、无密码流程。
  • 准备房间页面覆盖非房主准备。
  • 战斗页覆盖结算提示和失败结果。
  • 出牌合法性由 cardPlayRules 和后端规则引擎测试覆盖。

3.2 场景二：房主创建房间并开局

用户画像：

  • 已登录。
  • 希望选择一套规则创建房间，邀请其他玩家加入。
  • 目标是房间配置正确，玩家到齐后能开局。

预期流程：

  1. 用户登录。
  2. 进入创建房间页。
  3. 加载可用规则列表。
  4. 选择规则、设置回合时间和密码。
  5. 创建房间并成为房主。
  6. 等待其他玩家加入。
  7. 玩家准备后开始游戏。

当前测试覆盖：

  • 创建房间页加载规则并创建房间。
  • 无规则时显示校验提示。
  • 准备房间页展示房间摘要。
  • 房主开始游戏后跳转战斗页。

3.3 场景三：规则作者设计并上传规则

用户画像：

  • 希望用规则构建器设计自己的卡牌玩法。
  • 目标是编辑规则结构、配置牌型和流程，先保存为草稿，确认可运行后完成并上传，供创建房间时选择。

预期流程：

  1. 登录后进入规则构建器。
  2. 编辑基础信息、玩家/牌/牌桌属性。
  3. 配置牌型构建流程和比较流程。
  4. 查看导出 JSON。
  5. 保存草稿，后续可继续编辑该草稿。
  6. 确认规则流程可运行后，点击完成并上传规则。
  7. 在创建房间时选择该规则。

当前测试覆盖：

  • 规则构建页面渲染。
  • 工作区切换。
  • 保存草稿、编辑草稿和 JSON 预览按钮。
  • 构建步骤展示。
  • JSON 坐标导出和导入恢复。

4. 测试矩阵

操作系统 浏览器 用户登录注册 创建/加入房间 准备与离开房间 开始游戏/对局展示 创建规则 保存/编辑草稿 完成并上传规则 结论
Windows 11 Microsoft Edge 通过 通过 通过 通过 通过 通过 通过 通过
Windows 11 Chrome 通过 通过 通过 通过 通过 通过 通过 通过
Ubuntu 24.04 LTS Firefox 通过 通过 通过 通过 通过 通过 通过 通过

5. Alpha 出口条件

我们认为 WildCard Alpha 版本可以发布，需要满足下面条件。

5.1 功能条件

  • 用户可以完成注册、登录和退出。
  • 用户可以创建房间。
  • 用户可以通过房间号加入房间。
  • 房间内玩家可以准备。
  • 房主可以开始游戏。
  • 至少一套内置规则可以完成从开局到结算的流程。
  • 前端可以展示对局结算结果。
  • 规则构建器可以导出后端可解析的规则 JSON。

5.2 质量条件

  • 前端单元/组件测试全部通过。
  • 前端构建通过。
  • 基础 E2E 测试通过。
  • 后端 fmt、clippy、cargo test 全部通过。
  • 不存在会阻断主流程的bug。
  • 已知问题有记录，并确认不影响 Alpha 演示闭环。

5.3 本轮判断

从自动化测试结果看，当前代码已经满足“基础回归通过”的条件。
但从完整产品验收角度看，真实数据库、真实 HTTP、真实 WebSocket 和完整多人对局 E2E 仍然不足。因此当前状态适合作为 Alpha 阶段的可演示版本，但还不适合作为稳定公开版本。

6. 遗留问题与 Beta 测试计划

6.1 遗留问题

编号 问题 影响 计划
LEFT-001 WebSocket 真实链路覆盖不足 当前主要验证 room session 数据结构，不能充分证明多客户端实时同步、断线重连和广播顺序稳定 补充真实 WebSocket 多客户端测试
LEFT-002 规则引擎复杂规则覆盖仍不足 已覆盖基础解析和部分边界，但多牌型、跨牌型、循环流程、方法调用等场景仍可能出现规则执行 bug 增加复杂规则 fixture 和规则引擎回归集
LEFT-003 测试数据体现不够自动化 当前报告主要写通过/不通过，缺少覆盖率、用例数量变化、失败趋势等自动统计数据 接入 coverage、测试结果汇总和 CI artifact
LEFT-004 完成并上传规则的错误提示不够明显 不符合规则运行要求时会阻止上传，但错误位置和修复建议不够直观，用户不容易判断该改哪里 优化规则校验提示和错误定位
LEFT-005 接口错误信息一致性不足 前后端不同模块的失败 message、状态码和页面提示不完全统一，排查问题时成本较高 梳理 API 错误码和前端提示映射
LEFT-006 回归测试分层还可以更清晰 单测、组件测试、E2E、手工验证之间的边界仍有重叠，后续维护时容易重复补用例 重整测试分层和用例编号规则

6.2 Beta 测试计划

Beta 阶段测试重点从“能跑通”转向“跑得稳、测得准、报告可追踪”。

计划补充：

  1. 补真实 WebSocket 多客户端测试，覆盖加入、离开、准备、开局、出牌广播和断线重连。
  2. 为规则引擎增加复杂规则 fixture，覆盖多牌型、跨牌型比较、循环检测、方法调用和排序节点。
  3. 在 CI 中输出前端/后端覆盖率、测试用例数量、失败用例摘要和历史趋势。
  4. 优化完成并上传规则时的校验反馈，明确指出不可上传的原因、错误节点和建议修复方式。
  5. 梳理统一 API 错误码、后端 message 和前端提示文案，减少同类错误表现不一致的问题。
  6. 重新整理测试分层，把单元测试、组件测试、E2E、手工验收和报告编号对应起来。